The CBB division designs SOCs for set-top box applications and cable, satellite, and terrestrial communications. Most of its designs are fabricated in an 0.18-micron process using proprietary 32-bit processor cores and general-purpose blocks, along with dedicated functions designed specifically for the targeted application. In addition, these designs include analog blocks such as analog-digital converters, digital-analog converters, phase-lock loops, as well as 20 to 30 different memory blocks of various types and sizes. The resulting 2-million gate designs typically operate at 100-200 MHz with about 350 signal I/O pins on a ball-grid array.

To manage designs of this complexity, the CBB design team handles each SOC as a number of blocks-15 to 20 depending on the specific design. About half of these blocks are soft macros. The others are hard intellectual property (IP), including blocks procured from external IP vendors for standard functions such as PCI, Ethernet, and others.

The design environment

In today's competitive marketplace, a large design can be too expensive to compete effectively in the marketplace. So the ability to accurately predict design size is particularly critical for achieving profitable return on a complex SOC. In the past, delays in timing convergence, and therefore in chip assembly, have played a significant role in delays. More recently however, the CBB design organization's adoption of block-based design has led to dramatic improvements over earlier approaches that relied largely on manual, bottom-up design techniques. Block-based design is the automated physical implementation of a chip using blocks as the fundamental design element. In the block-based design flow, engineers work with blocks comprising thousands of cells rather than with the individual cells, thus providing a higher level of abstraction necessary for dealing with complex multi-million-gate SOC designs.

In this approach, designers work with block-based tools, which automate top-level design planning and interact with existing cell-based block implementation tools to help maintain top-level timing and area design objectives.

Figure 1 - Design flow

CBB designers use a top-down flow that combines block-based design tools for top-level design planning with cell-based design tools for block implementation.

The CBB design environment comprises a combination of tools from various EDA vendors, including Aristo, Synopsy, Cadence, and Mentor Graphics (see Figure 1). IC Wizard (Aristo) performs design planning and serves as the "hub" for physical budgeting down to the top-level floorplan, I/O ring definition and pin optimization. Designers also use IC Wizard to handle floorplan engineering change orders (ECOs) arising from later, bottom-up assembly. Floorplan information is transferred though TCL commands from IC Wizard to Chip Architect (Synopsys) along with the netlist. CBB uses Chip Architect for timing budgeting and PrimeTime (Synopsys) for timing signoff. Chip Architect also derives the synthesis constraints for block implementation, and Physical Compiler (Synopsys) is used for timing convergence at the block level. Finally, Flexroute (Synopsys) is used for top-level channel routing, while Ctgen (Cadence) is used for high fanout nets and clock tree synthesis, Wroute (Cadence) is used for block-level, detailed routing, and Calibre (Mentor) is used for block-level, design rule checking. Because CBB's design approach looks to exercise timing convergence at the placement level-before Ctgen and Wroute-these latter tools operate as standalone tools for their specific tasks. Tools from Aristo, Synopsys and Cadence exchange data through Verilog-format netlists, TCL scripts, and LEF/DEF -an approach that's proven to work well in practice.

We believe a top-down, block-based design approach provides better insight into the timing and area of a new device. We also see several things to recognize for top-down design: the need to assess timing as early as possible; and the need for a fast-reacting floorplanning system able to cope with last minute changes during the final chip assembly. The CBB design organization has been able to use block-based design to significantly cut the time from signoff to tapeout-an achievement that wasn't possible with older design methods. In earlier cell-based flows, designers would build complex designs from the bottom up-creating individual subsystems, or blocks, and later deal with the problems that arise when these subsystems are integrated. Now, however, top-level design of complex ICs must be accomplished first.

Automation boosts design

By allowing a "divide-and-conquer" approach, block-based design let individual designers tackle different portions of a design in parallel. For a number years, CBB designers have approached complex IC design through manual divide-and-conquer methods. Unfortunately, these manual practices introduced delays later in the development process. In particular, much of this delay occurred in chip integration when blocks were combined into the top-level design. At this point in the process, the design team would typically find that the actual size of the combined blocks exceeded the space allocated in the original floorplan, leading to significant changes and further delays as designers worked through multiple design iterations to bring the top-level design back into spec.

Unlike this bottom-up approach, block-based design relies on SOC infrastructure tools such as IC Wizard to automate top-level design tasks and updates. This tools-based design flow enables concurrent development of the top-level chip design and the individual blocks that make up the entire design.

To deal with problems arising from earlier manual practices, the CBB division adopted a block-based design approach that combines a variety of automated block-based and cell-based tools in a single design flow. As a result, designers gain a high level of concurrent design in the development process while ensuring predictable design closure.

Figure 2 - RTL Planning

In our work model the front-end designers take the block timing and physical constraints from the physical designers and look for problems.

By defining blocks with timing and area budgets, members of the design team implement each block independently. After the team has completed the correct top-level partitioning, front-end and back-end designers can work on the blocks in parallel-an approach that's simply not possible with flat design.

Additionally, as designers refine individual blocks, the results can be sent to the overall top-level design. And any top-level effects are carried over to other blocks if necessary. Even better, design teams can choose to enforce top-level timing or physical budgets and require individual blocks to meet their allocated budgets, thereby isolating each block from any"external" design impact.

It's true that a divide-and-conquer approach can result in final design sizes that fall short of the ideal optimized size. Still, even if flat design practices result in tighter final results, they do so only at the cost of a slower time to market and poorer predictability. Furthermore, flat approaches simply don't make sense with the complexity of designs today, even if existing cell-based tools could handle today's 2-3 million gate designs. In fact, today's SOC designs already exceed the capacity limitations of existing cell-based physical design tools. Next-generation designs will mandate block-based design tools.

Beyond the logistical advantages of block-based design, block-based tools simply let both front-end and back-end designers work more effectively. CBB designers are able to use existing flows, with minimal changes, using IC Wizard and Chip Architect. However, the tasks are split differently: In the CBB design flow, the front-end designer does most of the timing convergence.

In the past, the back-end designers who were trying to manage the timing convergence lacked sufficient knowledge of the design to focus on critical timing issues. Bringing this task forward, however, lets front-end designers handle the task. In the new CBB design flow, back-end designers write scripts to automate the placement and timing convergence phase for the blocks based on the top-level design. Furthermore, these back-end specialists don't execute those scripts, but pass them along to the front-end logic designer.

Design flow

For the front-end logic designer, this approximates a near push-button approach to incorporating physical design data. Using the values for timing constraints, block physical aspects, pin positioning-all derived by physical-design experts working on the top-level design-the front-end designer initiates the analysis, which automatically performs the calculations needed to verify timing convergence. At the end of this analysis, the front-designer receives timing reports that describe potential problems in the design, earlier than with traditional bottom-up design flows. Therefore, the front-end designer can iterate the design and improve concurrent design of individual blocks and the top-level design. The front-end designer can determine the full impact of a problem.

Unlike bottom-up design, we use the design floorplan as the centerpiece of the design flow. CBB designers use IC Wizard to support the floorplaning and physical budgeting flow and Chip Architect to support the timing budgeting flow (see Figure 2).

The initial step is a kind of prototyping step that starts as soon as a preliminary netlist of the top level is available. Prior to block development, designers develop only the netlist for the integration-the connections between the blocks. At this point, the design team doesn't care about internal block implementation details. Instead, designers focus on connectivity-related, inter-block issues such as the number of pins, bus connectivity and I/Os-top-level issues that are derived from the architecture of the device and will impact the performance of the IC. Based on these top-level specifications, the design team identifies the optimal floorplan by examining a set of alternatives generated by IC Wizard (see Figure 3). The tool is able to automatically create a user-specified number of alternative floorplans based on constraints and weighting criteria provided by designers. Pin optimization and power grid definition are handled during this step of the flow. From these results, physical boundary constraints for block level implementation are derived. They will be part of the global boundary constraints-along with timing constraints-for the block synthesis and implementation.

Figure 3 - Floorplan

After designers specify constraints and weighting criteria, IC Wizard automatically generates candidate floorplans. This floorplan plot shows the results for a communications SOC comprising a processor core, peripherals, analog macros, and several memory blocks.

In the second step, performed inside the Chip Architect environment, the design team focuses on timing budgeting for each block. Here, designers create a black-box timing model derived from the specification of each block. This model is critical because it allows the engineer to iterate a design at the top level and create refined timing budgets for each block required to meet top-level requirements. At this stage, designers must provide sufficient detail to specify the target timing relationship between pins of each block, specifying enough information on clocks and signal I/Os inside each block to build a preliminary timing model at the top level. Using these results for each block, the team can determine if the circuit fits the global timing specification. Typically, a design will not meet the top-level timing specification, so we will iterate to some degree to detail the exact budget for each block before beginning any block implementation. Once achieved, boundary-timing constraints are derived for block synthesis.

In the third step, we refine top-level routing, and account for signal integrity issues at the top level while block implementation proceeds. In addition, designers begin to take into account power supply issues, such as analog blocks and I/O, which up until this step didn't require any detailed attention. In parallel with this activity, block-level implementation occurs, using physical synthesis to help ensure timing convergence at the block level. Because of the top-level design work performed in the previous two steps, this step produces a high degree of parallelism between the top-level design and individual block implementation. CBB has found that this step yields significant savings in design time compared to other design methods.

During the fourth step, the top-level representation is updated with the actual size of the blocks-a process requiring two to three hours by IC Wizard. Automatic floorplanning capability allows small changes at the block level to be quickly accounted for. As design team members refine their blocks, individual blocks may grow or shrink. Consequently, this fourth step is required to continually update the top-level design, which in turn is needed to reconcile individual block-level changes. CBB designers approach this step as a day-to-day refinement that in practice depends on the number and severity of changes. If there are multiple small changes, the team usually waits and performs an update after the changes have stabilized. Alternatively, if there have been major changes, the design team updates the floorplan as soon as possible so the affected blocks can be refined as necessary.

In the final timing-signoff stage, CBB designers have found minimal problems, due to the continuous refinement up to this point. In theory, problems in the flow shouldn't develop because the CBB design method follows the deterministic budgeting approach described above. In practice, some small fixes may be required due to small differences in results derived from the different tools used in the CBB design flow. However, any required fixes are only local in nature. For example, some wire may have a little more capacitance than forecast. In the past the timing signoff step was characteristically a major ordeal because the design team would discover major problems at the end that would affect multiple blocks and take the design out of spec. Because block-based design continuously refines results, major problems don't appear at the end the design process.

The CBB SOC designers find that during the design cycle, top-down block-based design simplifies implementation of local changes because such changes are constrained by the top to remain local to a block, while not impacting neighboring blocks. Design iterations are essentially eliminated during final chip integration.

CBB designers need no additional iterations for timing, and just one for tuning physical results. The lack of interations arises from the fast reaction time enabled by IC Wizard during the design planning stage, where designers work with preliminary data. Typically, after designers build the first reasonable floorplan-a process that takes less than a week-they can implement further modifications in a few hours.

We now have an overall cycle time that takes less than two months for block implementation and chip integration. Because of the parallelism of front-end and back-end design, tape out then occurs predictably about two weeks after functional validation. The integration phase has been shortened by about a factor of two compared to earlier design methods.

Block-based design provides major benefits compared to flat design. First, block-based design injects maximum parallelism in design tasks, enabling concurrent design on top-level design and individual blocks. Second, this approach brings more physical data forward to the front-end design world and, as a result, designs achieve timing convergence more predictably. Finally, it's easier for designers to reuse designs-either from internal design blocks or external IP. For CBB, block-based design answers the need for improved time to market and profitability.

Francois Remond is the design support manager at STMicroelectronics' consumer broadband division in Grenoble, France

To voice an opinion on this or any other article in Integrated System Design, please e-mail your comments to mikem@isdmag.com.